Disaster Recovery

Preparing for recovery of your Keyfactor Command server in the event of a disaster or in anticipation of a planned event such as a software upgrade or hardware migration involves backing up several different components. The bulk of the data for a Keyfactor Command server implementation is stored in a SQL database, so backing up this SQL database regularly is key. A portion of the data stored in this database is encrypted, so you will need the appropriate components to allow you to access this encrypted information.

Ideally, your disaster recovery plan would include backing up each server hosting a Keyfactor role as a whole entity. This greatly simplifies recovery. With a plan of this sort, you would need these backed up components:

• Keyfactor Servers

  Each server hosting a Keyfactor role—your Keyfactor Command servers, any Keyfactor orchestrators, etc.—should be backed up as entire entities with the full OS and installed applications.

• Your Keyfactor Command SQL Database

  All the Keyfactor Command data—both configuration data and synchronized data such as certificates—is contained within one database, which should be backed up regularly.

• The SQL server Database Master Key (DMK) and Service Master Key (SMK) for your SQL Database

  If you need to restore your SQL database to a different SQL server instance than the one from which it was backed up, you will need either the DMK or the SMK. There are pros and cons to restoring with each of these, so it can be useful to have both available when you make the restore decision. These only need to be backed up once unless you change either of these in SQL. See SQL Encryption Key Backup.

If backing up each server as a whole entity is not feasible or you would like to also back up components on the servers that differ from a stock install, consider including the following items for backup:

• Your nlog.config Files

  The various Keyfactor Command server components and most other Keyfactor products have an nlog.config file that sets the logging level for the product and the output path for the log files. If you have made any customizations to any of these configuration files, you may find it useful to make a backup of them. For Keyfactor Command server, the Nlog.config files for the various Keyfactor Command components are in application-specific subdirectories under the installation directory, which is by default:

  C:\Program Files\Keyfactor\Keyfactor Platform

  For example:

  C:\Program Files\Keyfactor\Keyfactor Platform\WebConsole\NLog_Portal.config
  C:\Program Files\Keyfactor\Keyfactor Platform\KeyfactorAPI\NLog_KeyfactorAPI.config

• Customizations for PAM Configuration

  If you have implemented a PAM solution and manually made configuration changes for this (see Preparing Third Party PAM Providers to Work with Keyfactor Command), you may want to include these files in a one-time backup.

• Event Handler Scripts

  If you have implemented any event handler scripts for alerting (see Using Event Handlers), you may want to backup these files.

• PowerShell Scripts for Workflow A workflow is a series of steps necessary to complete a process. In the context of Keyfactor Command, it refers to the workflow builder, which allows you automate event-driven tasks when a certificate is requested or revoked.

  If you have implemented any custom PowerShell steps for that use external scripts (see Workflow Definitions), you may want to backup these files.

• Any Other Text-Based Files

  If you have modified any other text-based configuration files on your Keyfactor Command server (this is uncommon), you will want to have a one-time backup of these.

The process of restoring from backup depends on the components that have been affected. If only the Keyfactor Command server has been lost but the database is intact, the server may be restored from backup and re-connected to the existing database. If a whole server backup does not exist, a fresh server may be installed, Keyfactor Command installed again and connected to the existing database, and any customized files restored or recreated. If the SQL database is lost, the database must be restored from backup along with either the DMK or SMK (see SQL Encryption Key Backup).

For assistance with disaster recovery planning or implementation, please contact Keyfactor support (support@keyfactor.com).